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Les threads en Java 



Ce document est aussi disponible en postscript . 



1 Generalites 

La machine Java fournit le support d'un noyau de gestion d'activites (ou processus legers, ou threads). 
Lorsqu'une machine Java est demarree, elle cree une premiere activite applicative (qui appelle la procedure 
main de la classe specifiee), puis des activites peuvent etre creees et detruites dynamiquement. La methode 
System, exit permet d'arreter globalement la machine par un appel explicite. Sinon, P execution de la 
machine se poursuivra jusqu'a la terminaison de toutes les activites applicatives. Hormis ces activites 
applicatives, un certain nombre de activites dites demoniques gerent des activites de supervision (ramasse- 
miettes par exemple). 

Le cycle de vie d'une activite Java est similaire au cycle de vie standard d'une activite des Threads Posix, 
ou d'un processus : 



cree 



start 



notify, 
interrupt 



executable (actif) 



on-CPU 



bloque 
(synchro ou sleep) 




Un du code 



termine 



read, accept. 



bloque 
(E/S) 



, et positionne avant 



Une activite est caracterisee par les attributs suivants : 

• un nom externe (string), defini a la creation (explicitement ou avec une valeur par defaut), 

accessible par Thread. getName ( ) et modifiable avec Thread. setName (String) . 

• etat demonique : herite de Pactivite creatrice, est teste avec Thread. isDaemon 
le demarrage de I'activite par Thread. setDaemon (booi) . 

• priorite : heritee de Pactivite creatrice, est consultee et modifiee par Thread. getPriority ( ) et 
Thread . setPr ior ity ( int ) . Cette priorite est utilisee pour Pordonnancement a court terme (partage 
du processeur entre les activites executables) : quand la machine Java est disponible et doit 
selectionner une nouvelle activite, elle choisit une (au hasard) des activites ayant la priorite la plus 
elevee. A priori, la machine Java n'est pas preemptible (cf 43). 

• appartenance a un groupe : defini a la creation (explicitement ou par heritage de Pactivite creatrice), 
accessible par Thread . getThreadGroup ( ) (non modifiable). Voir 5.2 . 



2 Definition et creation d'une activite 



Une activite peut etre creee de deux manieres : 
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• Heritage de la classe Thread : on definit une classe qui herite de Thread et (re)definit la methode run 

class X extends Thread { 

public void run ( ) { 

... code de 1' activite ... 
} 

} 

// Utilisation 
foo() { 

X x = new X ( ) ; 

x . start ( ) ; 

x . j o i n ( ) ; 
} 

• Implantation de l'interface Runnabie : on definit une classe qui implante l'interface Runnabie (ce qui 
consiste simplement a definir une procedure public void run ( ) ), et on cree une instance de 

Thread avec un objet Runnabie : 
class X implements Runnabie { 

public void run ( ) { 

... code de 1 ' activite ... 

} 

} 

/I Utilisation 
food { 

X x = new X (...) ; 

Thread t = new Thread (x) ; 

t . start ( ) ; 

t . j o i n ( ) ; 
} 

• Pieges : 

o distinguer la methode run (qui est le code execute par l'activite) et la methode start (methode 
de la classe Thread qui rend l'activite executable) ; 

o dans la premiere methode de creation, attention a definir la methode run avec strictement le 
prototype indique (il faut redefinir Thread . run et non pas la surcharger). 

3 Operations de la classe Thread 

3.1 Les constructeurs 

Une activite est creee en fournissant plus ou moins de parametres explicites. Trois elements interviennent : 
le groupe, l'objet de la classe Runnabie fournissant le code a executer, un nom externe. 

Par defaut, un nom externe de la forme "Thread-" + <entier> est attribue a l'activite. 

Thread (ThreadGroup, Runnabie, String); 

Thread (ThreadGroup, Runnabie); 

Thread (ThreadGroup, String); 

Thread (Runnabie , String); 

Thread (Runnabie ) ; 

Thread ( String ) ; 

Thread ( ) ; 
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3.2 Methodes de classe 

• static Thread currentThread ( ) permet d'obtenir l'activite appelante ; 

• static void yield o laisse une chance aux autres activites de s'executer ; 

• static void sleep(long millisec) throws InterruptedException Suspend 1'exeCUtion de 

l'activite appelante pendant la duree indiquee ou jusqu'a ce que l'activite soit interrompue (voir 3.4 ) ; 

3.3 Vie de l'activite 

• void start ( ) rend l'activite executable apres sa creation ; 

• void join() throws InterruptedException attend que l'activite soit terminee ; 

• void join (long millisec) throws InterruptedException attend que l'activite Soit terminee 

ou que le delai de garde soit ecoule. 

3.4 Interruption 

La classe Thread fournit un mecanisme minimal permettant d'interrompre une activite : la methode 
interrupt (appliquee a une activite) provoque la levee de l'exception InterruptedException si l'activite 
est bloquee sur une operation de synchronisation (suite a un appel a ob j ect . wait, Thread . j oin ou 
Thread, sleep). Sinon, un indicateur interrupted est positionne. Cet indicateur est teste par deux 
methodes : 

• boolean isinterrupted ( ) qui renvoie la valeur de l'indicateur de l'activite sur laquelle cette 
methode est appliquee ; 

• static boolean interrupted ( ) qui renvoie et efface la valeur de l'indicateur de l'activite 
appelante. 

Noter que ce mecanisme ne permet pas d'interrompre une entree-sortie bloquante en cours (comme une 
lecture en attente de donnee) : l'indicateur d' interruption est positionne, mais aucune exception n'est levee 
et l'activite reste bloquee. Ce point limite considerablement Pinteret de ce mecanisme. 

4 Problemes et difficultes 

4.1 Activites + Objets ^ Acteurs 

En depit du mode de creation, l'activite n'est pas associee a l'objet qui a servi a la creer. Considerons 
l'exemple suivant : 

class X extends Thread { 

public void f oo ( ) { System. out. println (Thread. currentThread ( ) . getName ( ) ) ; } 
public void run ( ) { 

this.foo () ; // (1) 
} 
} 

class Y extends Thread { 
X unX; 

Y (X _x) { unX = _x; } 
public void run ( ) { 

unX.fooO ; // (2) 
} 
} 
public class Conf usionActeurs { 

public static void main (String[] unused) { 
X x = new X ( ) ; 
x. setName ( "Tl") ; 
x . start ( ) ; 
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Y y = new Y (x) ; 
y . setName ( "T2") ; 
y . start ( ) ; 

x.fooO; // (3) 

} 
} 

L'appel 1 produit ti, l'appel 2 produit T2 et l'appel 3 produit main, alors que tous s'appliquent au meme 
objet. C'est pourquoi, il est souvent preferable d'utiliser la deuxieme forme de creation (implantation de 
Runnabie), qui evite la confusion entre l'activite et l'objet. 

4.2 Absence de suicide 

La classe Thread ne prevoit qu'une seule cause de terminaison d'une activite : quand l'execution du code 
associe (methode run) est termine (que ce soit en atteignant proprement la fin de la procedure, par un 
return place dans run, ou a cause d'une exception non capturee, levee dans une methode appelee depuis 
run, ce dernier cas entrainant l'arret de la machine virtuelle). II est cependant possible de realiser le suicide 
ainsi : 

class ThreadSuicide extends Error { 

// Error est une forme de Throwable qu'il n' est pas necessaire de 
II declarer dans la clause throws des methodes qui la levent. 

/I Sauf cas tres particulier (comme ici) , elle ne doit jamais etre capturee. 
public static void exit ( ) { 

throw new ThreadSuicide ( ) ; 
} 
} 

class X extends Thread { 
public void run ( ) { 
try { 

... f oo ( ) ; ... 
} catch (ThreadSuicide e) { 
} 
} 

void f oo ( ) { // dans n' importe quelle classe 

if (! bon) 

ThreadSuicide . exit ( ) ; 
} 

4.3 Preemption et ordonnancement a court terme 

La specification de Java est tres imprecise sur la preemption et 1' ordonnancement des activites. La seule 
chose qu'exige la norme est la gestion des priorites telle que decrite en 1 : quand la machine Java est 
disponible et doit selectionner une nouvelle activite, elle choisit une (au hasard) des activites ayant la 
priorite la plus elevee. La machine Java devient disponible quand une activite se bloque (appel a 

object .wait, Thread, join ou Thread, sleep) ou accepte de ceder le processeur (appel a 

Thread, yield). 

Deux points sont done problematiques : que se passe -t-il quand une activite se bloque sur une entree-sortie 
? Que se passe-t-il si une activite de calcul faiblement prioritaire ne relache pas volontairement le 
processeur ? 

En pratique, il existe (au moins !) deux implantations des Threads dans Java : 

• les « green threads », implantes en interne a la JVM (machine virtuelle Java), non preemptif, mais 
assurant la commutation sur entree-sortie bloquante ; 

• les « native threads », utilisant une bibliotheque dediee au materiel sur lequel s'execute la JVM. Dans 
le cas de Java 1 .2 sur Solaris, la bibliotheque utilisee est celle des Threads Posix, ce qui assure le 
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non-blocage de la JVM sur E/S, la preemption avec partage de 1'acces au processeurs, et l'utilisation 
eventuelle de plusieurs processeurs materiels. Ce mode est le mode par defaut. 

5 Divers 

5.1 Variables localisees 

Outre les references globales (attributs des objets, visibles par toutes les activites) et les variables locales 
(visibles uniquement au sein de la fonction et par l'activite appelante), il existe des variables globales ayant 
une valeur distincte dans chaque activite. Le nom d'une activite peut etre percu comme une variable 

localisee- 

De telles variables sont des instances de ThreadLocai ou de inheritabieThreadLocai qui fournissent 
1' interface suivante : 

• public ob j ect get ( ) permet d'obtenir la valeur de la variable localisee pour l'activite appelante ; 

• public void set (object) permet de positionner la valeur de la variable localisee pour l'activite 
appelante ; 

• protected ob j ect initiaivaiue ( ) peut etre redefinie pour qu'une activite dispose d'une valeur 
par defaut autre que null. 

Remarquer qu'il n'est pas possible de consulter ou de modifier la valeur d'une variable localisee d'une 
autre activite. 

L'exemple suivant cree des activites qui disposent chacune d'un numero different (determine a leur premier 
appel a numero . get ( ) ). Le numero de l'activite courante est obtenu depuis n'importe quelle methode en 

Utilisant DemoThreadLocal . numero . get ( ) . 

class NumeroThread extends ThreadLocai { 
static int numeroCourant = ; 
protected Object initialValue ( ) { 
numeroCourant++ ; 

return new Integer (numeroCourant ) ; 
} 
} 

class Activite implements Runnable { 
public void run ( ) { 

System. out . println ( "Mon numero est " + (Integer) DemoThreadLocal . numero . get ()) ; 
} 
} 
public class DemoThreadLocal { 

static NumeroThread numero = new NumeroThread () ; 
public static void main ( String [ ] unused) { 
for (int i = 0; i < 5; i++) { 
Activite a = new Activite ( ) ; 
new Thread(a). start (); 
} 
} 
} 

5.2 G roil pes d 'activites 

Les activites peuvent etre structurees en groupes (classe ThreadGroup). Implicitement, toutes les activites 
appartiennent au groupe systeme (racine). D'autres groupes peuvent etre crees. Une hierarchie peut exister 
entre les groupes selon une structure d'arbre. Cette notion permet en particulier de declencher une 
operation sur tous les membres d'un groupe (changement de la priorite des activites du groupe, enumeration 
des activites du groupes. . .). 
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5.3 Exercice 

Ecrire un programme qui contient trois activites : 

• l'activite Aaffiche "toto" toutes les deux secondes ; 

• l'actitite B additionne iterativement les nombres de 1 a 5000 ; 

• l'actitite C affiche "true" toutes les trois secondes ; 

• le programme principal attend la terminaison de B et termine alors 1' application. 

Proposer des solutions avec et sans join. 

6 La synchronisation 

Les activites interagissent lorsqu'elles entrent en concurrence pour l'acces a des objets communs ou quand 
elles cooperent via des objets partages. De facon classique, on trouve deux niveaux de synchronisation : 
d'une part, le probleme de Pexclusion mutuelle d'acces a des donnees (objets) ou a du code (des 
methodes), d' autre part, le probleme de la synchronisation sur des evenements. La combinaison des deux 
forme dans Java des moniteurs de Hoare degeneres. 

6.1 L' exclusion mutuelle 

Pour traiter les problemes d'exclusion mutuelle, Java propose la definition de sections critiques exprimees a 

Paide du mot cle synchronized. 

• Tout objet Java est equipe d'un verrou d'exclusion mutuelle. Ainsi, pour assurer qu'une seule activite 
accede a un objet unob j d'une classe quelconque, on definit les actions sur l'objet dans une region 
critique par la syntaxe : 

synchronized (unObj) { 

< Region critique > 
} 

• Une methode peut aussi etre qualifiee de synchronized : 

synchronized T uneMethode (...) { ... } 

Ceci est equivalent a : 

T uneMethode (...) { 

synchronized (this) { ... } 
} 

II y a done exclusion d'acces de l'objet sur lequel on applique la methode, pas de la methode 
elle-meme, qui peut etre executee concurremment sur des objets differents. 

• Chaque classe possede aussi un verrou exclusif qui s'applique aux methodes de classe (methodes 
statiques) : 

class X { 

static synchronized T too ( ) { ... } 

static synchronized T" bar ( ) { ... } 
} 

L'utilisation de synchronized assure ici l'execution en exclusion mutuelle pour toutes les methodes 
statiques synchronisers de la classe x. Noter que ce verrou ne concerne pas l'execution des methodes 
d'objets. 

• Les verrous sont qualifies de recursifs ou reentrants : si une activite possede un verrou, une 
deuxieme demande provenant de cette activite est satisfaite sans causer d'auto-interblocage, et le 
code suivant s' execute sans probleme : 
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synchronized ( o) { ... synchronized ( o) { ... } ... } 

En programmation « propre », on evitera cependant de dependre de cela. 

6.2 L'interblocage du aux verrous 

Avec l'utilisation de plusieurs verrous, le risque d'interblocage existe, des qu'une activite peut posseder 
plusieurs verrous. Par exemple, le code suivant ne garantit pas l'absence d'interblocage : 

synchronized (ol) { synchronized (o2) { ... } } 

I I 
synchronized (o2) { synchronized (ol) { ... } } 

La solution pour garantir l'absence d'interblocage par les verrous est la « strategic par classes ordonnees » : 
on definit une relation d'ordre (d'importance) sur tous les verrous et on assure que les activites acquierent 
les verrous exclusivement par ordre croissant d'importance. Dans l'exemple precedent, si ol est moins 
important que o2, la deuxieme ligne est erronee. En general, il est aise de verifier qu'un code proprement 
ecrit respecte la contrainte d'ordre. 

6.3 La synchronisation par objet 

Pour synchroniser des activites sur des conditions logiques, on dispose du couple d'operations permettant 
d'assurer le blocage et le deblocage des activites, en l'occurrence (wait, notify [All] ). Ces operations 
sont applicables a tout objet, pour lequel l'activite a obtenu au prealable l'acces exclusif. L' objet est alors 
utilise comme une sorte de variable condition. 

• unob j . wait ( ) libere l'acces exclusif a l'objet et bloque l'activite appelante en attente d'un reveil via 
une operation unobj .notify ; 

• unob j . notify ( ) reveille une seule activite bloquee sur l'objet (si aucune activite n'est bloquee, 
l'appel ne fait rien) ; 

• unob j . notify-All ( ) reveille toutes les activites bloquees sur l'objet. 

L' operation wait peut aussi se terminer par une interruption ( 3.4 ) ou apres un delai de garde specifie a 
l'appel. 

Dans tous les cas, lorsqu'une activite est reveillee, elle est mise en attente de l'obtention de l'acces exclusif 
a l'objet. 

6.4 Implantation des semaphores 

public class Semaphore { 

private int cpt = ; 
Semaphore (int c) { 

cpt = c; 
} 

public void P() throws InterruptedException { 
synchronized (this) { 
while (cpt == 0) { 

this . wait ( ) ; 
} 

cpt-- ; 
} 
} 

public void V() { 

synchronized (this) { 
cpt++; 
this . notify ( ) ; 
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6.5 Difficultes 

• Attention aux prises multiples de verrous : 

synchronized (ol) { synchronized (o2) { ol.wait () ; } } 

Dans ce cas, l'appel ol . wait ne libere que le verrou exclusif de ol, alors que le verrou exclusif de 02 
reste acquis a l'activite bloquee. 

• L' existence d'une seule notification possible pour une exclusion mutuelle donnee rend difficile la 
resolution de problemes de synchronisation. En depit d'une apparence similaire, les solutions 
inspirees des moniteurs de Hoare sont difficilement transposables si elles necessitent plus d'une 
variable condition. Deux voies securises s'offrent au pauvre programmeur Java : soit utiliser les 
semaphores dont 1' implantation a ete fournie ci-dessus ; soit affecter un objet de blocage distinct a 
chaque requete et gerer soit-meme les files d'attente. 

• II n'existe aucun ordonnancement garanti pour l'ordre de reveil des activites bloquees. En outre 
l'activite reveillee ne devient effectivement active que lorsqu'elle a reobtenu le verrou d'exclusion 
mutuelle, et l'etat peut avoir ete modifie entre temps. II est done indispensable de retester la condition 
de blocage (boucle while dans l'exemple ci-dessus). 

• Compte tenu des remarques precedentes, et en ajoutant le peu de garantie sur le partage processeur 
(4.3), garantir la vivacite des activites est difficilement soluble. 

6.6 Gestion explicite des files d'attente 

La solution la plus simple (mais pas la plus elegante) pour resoudre reellement un probleme de 
synchronisation en Java consiste en la gestion explicite des requetes bloquees. On definit ainsi une classe 
Requete, qui contient les parametres de demande. Quand une requete ne peut pas etre satisfaite, on cree un 
nouvel objet Requete, on le range dans une structure de donnees, et l'activite demandeuse se bloque sur 
l'objet Requete. Quand une activite modifie l'etat de sorte qu'il est possible qu'une (ou plusieurs) requete 
soit satisfaite, elle parcourt les requetes en attente pour debloquer celles qui peuvent l'etre. La condition de 
satisfaction et la technique de parcours permet d'implanter precisement la strategic souhaitee. 

La premiere difficulte provient de la protection des variables partagees par toutes les activites (etat du 
systeme et des files d'attente) tout en assurant un blocage independant ; cela conduit a l'apparition d'une « 
fenetre », ou une activite tente de debloquer une autre activite avant que celle-ci n'ait effectivement pu se 
bloquer. La deuxieme difficulte reside dans l'absence d' ordonnancement lors des reveils, ce qui necessite 
que la mise-a-jour de l'etat soit faite dans l'activite qui reveille et non pas dans l'activite qui demande. On 
obtient alors la structure suivante (en italique, ce qui concerne specifiquement le probleme resolu : 
l'allocateur de ressources) : 

class Allocateur { 

private class Requete { 

boolean estSatisf aite = false; 

int nbDemande ; I / parametre d'une requete 

Requete (int nb) { nbDemande = nb ; } 
} 

// les requetes en attente de satisfaction 

j ava . util . List lesRequetes = new j ava . util . LinkedList ( ) ; 

int nbDispo = ... ; // le nombre de ressources disponibles 

void allouer (int nbDemande) throws InterruptedException 

{ 

Requete r = null; 
synchronized (this) { 
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if ( nbDemande <= this . nbDispo) { I / la requete est satisfaite immediatement 

this . nbDispo -= nbDemande ; // maj de 1'etat 

} else { // la requete ne peut pas etre satisfaite 

r = new Requete (nbDemande) ; 
this . lesRequetes . add (r); 
} 
} 

// fenetre => necessite de estSatisf aite (plus en excl . mutuelle done une autre 
// activite a pu faire liberer, trouver cette requete et la satisfaire avant 
// qu'elle n' ait eu le temps de se bloquer ef f ectivement ) . 
if (r != null) { 

synchronized (r) { 

if (! r . estSatisf aite ) 

r . wait ( ) ; 
// la mise a jour de l'etat se fait dans le signaleur. 
} 
} 
} // allouer 

public void liberer (int nbLibere) 

{ 

synchronized (this) { 

this . nbDispo += nbLibere ; 

I / strategic bourrin : on reveille tout ce qu'on peut. 
j ava . util . Iterator it = lesRequetes . iterator () ; 
while (it .hasNext ( ) ) { 

Requete r = (Requete) it . next ( ) ; 
synchronized (r) { 

if (r . nbDemande <= this . nbDispo) { II requete satisfaite ! 
it . remove ( ) ; 

this . nbDispo -= r . nbDemande ; // maj de l'etat 
r . estSatisf aite = true; 
r . n o t i f y ( ) ; 



} 



} 

} 
} 
} // liberer 



1 

La norme Posix Threads utilise le terme de specific data. 



Ce document a ete traduit de L T^Xpar H^V-A 
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